1. Field of the Invention
The invention relates to serial bus transfers capable of handling several types of serial bus devices, and more particularly to an arbiter for managing operation and timing of device operations on the serial bus.
2. Description of the Related Art
Computer systems are becoming ever more powerful with each passing moment. Many new advanced bus structures such as PCI or Peripheral Component Interchange bus have been developed to allow greater performance of the computer system. Additionally, new devices and uses are being developed for the computer systems. In the past the computer has been essentially a standalone device or networked with other computer systems. However, today the modern personal computer is becoming a much more connected and multimedia oriented system. For example, now high speed video and audio functions are becoming commonplace and the integration with the telephone system has already begun.
However, many of these new features are well below the ultimate bandwidth or capability of the advanced buses such as the PCI bus. Therefore, it is not efficient to connect each one of the new functions and devices to the PCI bus directly, as this would impact bus loading and greatly increase overall costs. Additionally, many of these new functions are essentially serial in nature, with the data transferred in a bit stream rather than over a parallel bus structure. This is provided for many reasons, such as reduced wiring costs and can be done because of the lower data rates which are required.
Therefore, it has been proposed to develop a serial bus organization to connect all of these various lower bandwidth devices. The serial bus is organized with a host controller having a series of ports, which can then be connected either directly to devices or functions or to further hubs which have below them further devices or functions. A hub or the host controller may in addition incorporate functions if desired. In this manner a tree structure can be developed to allow a reasonable number of functions or devices to be attached to the serial bus system. The host controller connects to a bus in the computer system, for example the PCI bus, through the host controller. By having the host controller act as a concentrator, only a single connection to the PCI bus is necessary. The connection is better able to utilize the performance of that PCI bus without requiring numerous connections.
The host controller, each hub, and each function or port contain particular control registers for doing set up and initialization operations. In addition, three basic types of data transfer are defined in the serial bus system. The first type is isochronous, which is effectively a continuous real time transfer, such as telephony information or audio information. The second type is asynchronous block transfers, such as printer operations and conventional serial port operations, while the third type is asynchronous interactive device transfers, such as keyboard, mouse, pointing device, pen interfaces, and the configuration and status information, generally referred to as the control information, of the various devices.
Information is passed over the serial bus system when the host controller is a series of packets, with the host controller acting as the bus master and hubs and devices only responding upon request or polling access of the host controller. The packet types include data packets, token packets for use from host to device, a handshake packet and a special control packet. Data packets are the isochronous, asynchronous block, and asynchronous control types. Token packets allow transfer of data packets. Handshake packets are used to perform a ready handshake after transfer of a data or control packet to acknowledge successful receipt or indicate unsuccessful receipt. Special control packets are used for logical reset and status request transfers. Each function or device has a logical address.
Of most interest in this description are the three types of data transfers, isochronous, asynchronous block and control. It is noted that the control functions for both the isochronous and asynchronous block devices are done using control data transfers. An isochronous device needs a virtual channel having a given minimum bandwidth, so isochronous transfers must be requested or scheduled to have this minimum bandwidth. The bandwidth can be obtained by long block sizes and infrequent transfers, smaller block sizes and more frequent transfers, or a combination. An asynchronous block device need not have a guaranteed bandwidth, as they conventionally can have some flexibility in data transfer rates, but preferably the transfers must be robust so that when errors are detected, the transfer can be retried. Asynchronous devices come in essentially two types, high and low bandwidth. Higher bandwidth devices include printers and modems, while lower bandwidth devices are keyboards, mice and the like. The control functions are relatively low bandwidth. The control functions have essentially a one-time nature, being used mostly during system initialization and to prepare a device for a block transfer. In contrast, the isochronous and asynchronous block devices have a tendency to be very regular and thus operate differently from the control and interactive devices.
Each device and port on a hub or the host controller includes the capabilities to handle the low level bus transfer protocol between the particular node of the appropriate hub and the device itself. Thus, a relatively simple transfer protocol, with a limited number of packet types is defined.
However, of particular interest is the mechanism for allotting particular devices bandwidth in the serial bus system. In the preferred embodiment, the serial bus has a bandwidth of 5 to 20 Mb/sec, which must be split between the various devices. It is important that an isochronous device receive its guaranteed portion of that bandwidth, but it is also important that asynchronous block transfers and control transfers are not starved or overly delayed, if at all possible. Therefore, an arbiter or scheduler must be developed to properly coordinate the various transfers occurring in the serial bus system.
It is further desirable that the arbiter maximize utilization of the serial bus system at all times to allow the best performance of the devices in the serial bus system. It is further desired that significant portions of the arbiter be handled in hardware because of the greater speeds conventionally obtainable by hardware, in deference to the customarily slower operation of software based functions.